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Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2000). All Rights Reserved. 


Abstract 


AAA servers are in use within the Internet today to provide 
authentication and authorization services for dial-up computers. 

Such services are likely to be equally valuable for mobile nodes 
using Mobile IP when the nodes are attempting to connect to foreign 
domains with AAA servers. AAA servers today identify clients by 
using the Network Access Identifier (NAI). Our proposal defines a way 
for the mobile node to identify itself, by including the NAI along 
with the Mobile IP Registration Request. This memo also updates RFC 
2290 which specifies the Mobile-IPv4 Configuration option for IPCP, 
by allowing the Mobile Node’s Home Address field of this option to be 
zero. 
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Les 


Introduction 


AAA servers are in use within the Internet today to provide 
authentication and authorization services for dial-up computers. 

Such services are likely to be equally valuable for mobile nodes 
using Mobile IP when the nodes are attempting to connect to foreign 
domains with AAA servers. AAA servers today identify clients by 
using the Network Access Identifier (NAI) [1]. This document 
specifies the Mobile Node NAI extension to the Mobile IP Registration 
Request [7] message from the mobile node. 


Since the NAI is typically used to uniquely identify the mobile node, 
the mobile node’s home address is not always necessary to provide 
that function. Thus, it is possible for a mobile node to 
authenticate itself, and be authorized for connection to the foreign 
domain, without even having a home address. A message containing the 
Mobile Node NAI extension MAY set the Home Address field to zero (0) 
in the Registration Request, to request that a home address be 
assigned. 


The "Mobile-IPv4 Configuration" option to IPCP has been specified in 
RFC 2290 [8] for proper interaction between a mobile node and a peer, 
through which the mobile node connects to the network using PPP. 
According to that specification the Mobile Node’s Home Address field 
of the option MUST not be zero. However, in the context of this memo 
which allows a mobile node to be identified by its NAI and to obtain 
an address after the PPP phase of connection establishment, the Home 
Address field is allowed to be zero while maintaining all other 
aspects of RFC 2290. Interpretation of various scenarios from RFC 
2290 is given in section 4. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [3]. 


Mobile Node NAI Extension 


The Mobile Node NAI extension, shown in figure 1, contains the user 
name following the format defined in [1]. When it is present in the 
Registration Request, the Home Address field MAY be set to zero (0). 
The Mobile Node NAI extension MUST appear in the Registration Request 
before both the Mobile-Home Authentication extension and Mobile- 
Foreign Authentication extension, if present. 
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Figure 1: The Mobile Node NAI Extension 


Type 131 (skippable) [7] 
Length The length in bytes of the MN-NAI field 
MN-NAI A string in the NAI format defined in [1]. 


3. Foreign Agent Considerations 


If Home Address is zero in the Registration Request, the foreign 
agent MUST use the NAI instead in its pending registration request 
records, along with the Identification field as usual. If the 
foreign agent cannot manage pending registration request records in 
this way, it MUST return a Registration Reply with Code indicating 
NONZERO_HOMEADDR_REQD (see section 5). 


If the mobile node includes the Mobile Node NAI extension in its 
Registration Request, then the Registration Reply from the home agent 
MUST include the Mobile Node NAI extension. If not, the foreign 
agent SHOULD send the Registration Reply to the mobile node, changing 
the Code to the value MISSING_NAI (see section 5). The Registration 
Reply MUST include a nonzero Home Agent address and mobile node's 
Home Address. If not, the foreign agent SHOULD send the Registration 
Reply to the mobile node, changing the Code to the value 
MISSING_HOME_AGENT or MISSING_HOMEADDR, respectively (see section 5). 


4. Interactions with Mobile-IPv4 Configuration Option to IPCP 


In the Mobile-IPv4 Configuration Option to IPCP [8], the Mobile 
Node’s Home Address field may be zero. In this section, we specify 
the action to be taken in that case, when the mobile node is using 
the Mobile Node NAI extension in the Mobile IP Registration Request. 
Whether or not the IP Address Configuration Option contains a nonzero 
IP address, the mobile node will subsequently attempt to obtain a 
home address from the Mobile IP Registration Reply. 


If the IP Address Configuration Option to IPCP has IP address equal 


to zero, the PPP peer is expected to allocate and assign a co-located 
care-of address to the Mobile Node. If, on the other hand, the IP 
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Address Configuration Option to IPCP has a nonzero IP address, the 
PPP peer is expected to assign that address to the Mobile Node as its 
co-located care-of address. 


Finally, if the IP Address Configuration Option is left out of the 
IPCP Configure-Request, then no co-located care of address is 
assigned during IPCP. The mobile node will acquire a co-located care 
of address during a later stage of configuration or will use an FA- 
located care-of address. 


5. Error Values 
Each entry in the following table contains the name and value for the 


Code [7] to be returned in a Registration Reply, and the section in 
which the error Code is first mentioned in this specification. 


Error Name Value Section of Document 
NONZERO_HOMEADDR_REQD 96 3 
MISSING_NATI 97 3 
MISSING_HOME_ AGENT 98 3 
MISSING_HOMEADDR 99 3 


6. IANA Considerations 
The Mobile Node NAI extension defined in Section 2 is a Mobile IP 
registration extension as defined in RFC 2002 [7] and extended in RFC 


2356 [6]. IANA should assign a value of 131 for this purpose. 


The Code values defined in Section 5 are error codes as defined in 


RFC 2002 and extended in RFC 2344 [5] and RFC 2356 [6]. They 
correspond to error values conventionally associated with rejection 
by the foreign agent (i.e., values from the range 64-127). IANA 


should record the values as defined in Section 5. 


7. Security Considerations 


Mobile IP registration messages are authenticated, and the 
authentication verified by the recipient. This proposal does not 
prohibit the mobile node from sending its NAI in the clear over the 
network, but that is not expected to be a security issue. 


8. IPv6é Considerations 
Supporting NAI-based registrations for Mobile IPv6 [4] is outside the 
scope of this document. This section contains some ideas how 


Stateless Address Autoconfiguration [9] and DHCPv6 [2] might be 
extended to support NAI-based Mobile IPv6 registrations. 
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For mobile nodes using IPv6, there are no commonly deployed 
mechanisms by which a mobile node may present its credentials, such 
as exist today with IPv4. Nevertheless, a mobile node using IPv6 
mobility may wish to specify the domain in which their credentials 
may be checked, by using a NAI just as this specification proposes 
for IPv4. In the case of IPv6, however, there is no foreign agent in 
place to manage the connectivity of the mobile node, and thus to 
manage the verification of the credentials offered by the mobile 
node. To identify the HDAF (see appendix A) that has the expected 
relationship with the mobile node, the NAI would have to be forwarded 
to a local AAA by the local agent involved with configuring the 
care-of address of the mobile node. 


This agent can either be a router sending out Router Advertisements 
[9], or a DHCPv6 server. In the former case, the router could signal 
its ability to handle the NAI by attaching some yet to be defined 
option to the Router Advertisement. In the latter case, for managed 
links, the mobile node could include a yet to be defined NAI 
extension in its DHCP Solicitation message. Such an NAI extension 
and appropriate authentication would also be required on the 
subsequent DHCP Request sent by the mobile node to the DHCP Server 
selected on the basis of received DHCP Advertisements. Once a care- 
of address on the foreign network has been obtained, the mobile node 
can use regular MIPv6 [4]. 
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A. Home Domain Allocation Function (HDAF) 


This appendix introduces a new function named the Home Domain 


Allocation Function (HDAF) that can dynamically assign a Home Address 


to the mobile node. 


Figure 2 illustrates the Home HDAF, which receives messages from 
foreign agents (e.g., FA) and assigns a Home Address within the Home 
Domain. The HDAF does not perform any Mobile IP processing on the 


Registration Request, but simply forwards the request to a Home Agent 


(HA) within the network that is able to handle the request. 


+------ + +------ + +------ + | | 
i=. ai poo — 
| MN |------- | Fa |------- | HDAF +---+ 

} | } | Po ff tetttans 
+------ + +-----—- + +------ + | | | 


Figure 2: Home Domain Allocator Function (HDAF) 


Upon receipt of the Registration Request from the mobile node (MN), 
FA extracts the NAI and finds the domain name associated with it. 
then finds the HDAF that handles requests for the mobile node’s 
domain. The discovery protocol is outside of the scope of this 


specification. As an example, however, FA might delegate the duty of 


finding a HDAF to a local AAA server. The local AAA server may also 
assist FA in the process of verifying the credentials of the mobile 
node, using protocols not specified in this document. 
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Full Copyright Statement 
Copyright (C) The Internet Society (2000). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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